============================================================== Guild: wafer.space Community Channel: 📐 - Designing / 💻-digital After: 2026-06-30 11:59 p.m. Before: 2026-08-01 12:00 a.m. ============================================================== [2026-07-02 7:48 p.m.] deempak In my design while i was checking out the numbers I found that fanout/design repair is using dlyb_1 as for ordinary buffer is the what's suppose to happen ? These are being added by the repair_design command in the flow [2026-07-03 6:29 a.m.] mole99 Unfortunately, OpenROAD does not currently differentiate between data and hold buffers during buffer selection: https://github.com/The-OpenROAD-Project/OpenROAD/issues/10622 While you can disable all delay buffers, this would also mean that they could not be used for hold repair. [2026-07-03 6:29 a.m.] mole99 @RebelMike did a workaround for his design where he replaced all setup-repair dlyb with normal buffers iirc. [2026-07-03 11:22 a.m.] rebelmike Yes, I used the foundry cell library for my TT design and it had this issue. I wrote a quick librelane plugin to fix it that’s linked from here https://github.com/librelane/librelane/issues/967 you can see how I injected it into the config here: https://github.com/MichaelBell/ttgf0p3-tinyQV/blob/c02a42568e2f9dcf6b6ba6f78fe7b5f818b97e76/src/config.json#L73 (will need converting to yaml) And then I think you just need that plugin on the PYTHONPATH and it should work {Embed} https://github.com/librelane/librelane/issues/967 Feature request: Have an ECO step that can replace cells · Issue #... Description It would sometimes be useful to replace the cell for a given instance, e.g. to change buffer type or resize a cell to improve timing. This could be an ECO step similar to InsertECOBuffe... {Embed} https://github.com/MichaelBell/ttgf0p3-tinyQV/blob/c02a42568e2f9dcf6b6ba6f78fe7b5f818b97e76/src/config.json ttgf0p3-tinyQV/src/config.json at c02a42568e2f9dcf6b6ba6f78fe7b5f81... TinyQV including analog peripherals for TT GF 0.3. Contribute to MichaelBell/ttgf0p3-tinyQV development by creating an account on GitHub. {Reactions} 👍 [2026-07-04 8:57 a.m.] deempak ohh ok I tried to disable the delay cells this but the hold timing got bad so I will check the work around Btw would it effect the tapeout if the dlyb buffers are used instead of normal buffer ? [2026-07-04 8:59 a.m.] mole99 As long as STA says that you meet your timing requirements, then it should be fine even with dlyb. [2026-07-04 9:00 a.m.] deempak yup the STA is fine , Then i guess i will let it be {Reactions} 👌 [2026-07-09 6:25 p.m.] crockpotveggies Anyone here have full SOC designs and having issues with very long synthesis times? Our same design for fpga on vivado takes 15-30 minutes to synth, but on yosys we’re seeing 12+ hours despite enabling multi threading and other usual suspects. Is this a known issue? I opened a PR with yosys to merge some optimizations and it was rejected because it was “AI assisted” and I must admit the attitude was very disappointing despite providing follow ups, asking questions, etc. [2026-07-09 7:16 p.m.] 246tnt That's usually a sign you have synthesized memories or something like that [2026-07-09 8:09 p.m.] mole99 @J-Lo If you haven't read this page yet, you should do so before contributing to Yosys: https://yosyshq.readthedocs.io/projects/yosys/en/latest/yosys_internals/extending_yosys/contributing.html There are also some rules on LLM usage. [2026-07-09 8:09 p.m.] mole99 Often you can also speed up synthesis by keeping some parts of your design hierarchical. [2026-07-09 8:24 p.m.] crockpotveggies Yes we do leverage the keep_hierarchy. I’m aware of the LLM rules but frankly it felt like an aversion not a guardrail. But I’m not keen to focus this discussion on that, I’m trying to understand if our synth times are abnormal and if we need to investigate a problem [2026-07-10 12:04 a.m.] bailey8889 Just to be clear, you're referring to the actual yosys synthesis step and not the any of the place and routing steps, right? [2026-07-10 5:42 p.m.] crockpotveggies This is a summary from my team, and because I’m seeing openroad yes it might be PNR > synthesis/signoff runs were spending huge time in OpenROAD.RepairDesignPostGPL. The dominant cause was a massive high-fanout reset net: i_chip_core.rst_n had about 38,354 terminals, and OpenROAD was serially building buffer trees for it. LibreLane parallelism knobs do not help this step much. [2026-07-10 5:57 p.m.] bailey8889 Place and route runtimes are highly dependent on routing areas. Placing macros too close together or too close to the edges can result in unroutable designs. [2026-07-10 5:59 p.m.] crockpotveggies Thanks we do have an SRAM macro in there and I wonder if that’s what’s causing some of our issues. I will note it is routable and we get a GDS, it just takes an obscenely long time to create [2026-07-10 6:00 p.m.] bailey8889 Do you see any obvious congestion in the gds? [2026-07-10 6:08 p.m.] crockpotveggies Waiting for a file transfer of the final report but in summary I think you’re on to something, probably to do with the SRAM macro: > Dense SRAM macro grid. The current report has 39 SRAM macros consuming 4.48365 mm²; total core payload is 8.23514 / 12.90200 mm², about 64% including macros. In macros_3v3.yaml⁠, SRAM columns at x=1040 and x=1380 are only about 38.7 µm apart after subtracting the 301.3 µm SRAM width. {Reactions} 😮 [2026-07-10 6:12 p.m.] crockpotveggies I’m not sure how solvable this problem is with such a short time until tape out. I think it’s just a challenge posed by the small chip area and requirement to have an SRAM [2026-07-11 8:09 a.m.] mole99 Have you had a look at your design through the OpenROAD GUI yet? If you send a screenshot, people might be able to help you. {Reactions} ferristhumbsup [2026-07-13 10:36 a.m.] deempak Hello I was just doing final check up on the design and show that rst_n_pad is neither pu or pd is that normal or i can pull it down ? is there a reason for it being so ? [2026-07-13 10:38 a.m.] deempak As i have pulled up my cs_n pin for my input spi in the design so if there is some issue with that i should change that [2026-07-13 10:43 a.m.] rebelmike I don't see why there would be any issue using the pull up/down, it's just not used by default in the template {Reactions} ✅ [2026-07-13 10:47 a.m.] deempak Alright then thank you ============================================================== Exported 24 message(s) ==============================================================